前言

嘿，大家好！今天我們來聊聊如何設計一個飯店預訂系統的測試案例。這是一個我經常會用來測試分析能力和設計策略的練習，因為這樣的系統不僅場景複雜，而且能碰到很多實際情況，像是訂房變更、付款失敗、甚至是房間損壞等問題。

我們會用一種叫 Soap Opera Testing 的方法，這是一種有趣且實用的測試技巧，來自 Hans Buwalda。他的思路就是將測試場景變得像「肥皂劇」一樣，透過使用者的角度去描述一連串可能發生的情境，找到系統的潛在問題。

肥皂劇劇情測試 (Soap Opera Testing) 簡介

Soap Opera Testing 就像是一部充滿波折的肥皂劇劇情，不同的使用者會經歷各種突發狀況，這種方法最適合複雜且變動多的系統測試。具體來說，我們會圍繞某個使用者來設定場景，看看隨著訂房流程的變化，系統是否能穩健運作，並且能夠應對所有的變動。

這裡有個影片可以更詳細了解這個測試方法：

挑戰目標

我們今天的挑戰是：利用 Soap Opera Testing 來設計飯店預訂系統的測試案例，涵蓋從訂房、取消到重新訂房及付款問題等場景，目標是覆蓋大部分使用者可能遇到的情境。

系統需求

• 用戶可以選擇飯店、入住日期、退房日期、房型和入住人數來進行預訂。
• 預訂完成後，系統會生成預訂確認郵件，包含詳細訂房信息與付款資訊。
• 支持多種付款方式（信用卡、PayPal 等）。

劇情設計

讓我們設計一下使用者 Emily 的預訂過程，她的行程變動非常多，整個預訂系統都會被她搞得一團亂！她的故事如下：

1. 第一次訂房：Emily 先訂了一間飯店，計劃 2024 年 10 月 1 日入住，10 月 5 日退房。
2. 更改入住日期：因為工作調整，她將入住日期提前至 9 月 30 日。
3. 取消部分日期：後來，她決定取消 10 月 1 日至 10 月 2 日的住宿，改為只住 9 月 30 日至 10 月 1 日。
4. 再次訂房：突然她又改變主意，重新訂回 10 月 1 日至 10 月 5 日的房間。
5. 付款失敗：Emily 在嘗試付款時因銀行問題失敗，但重新付款後成功。
6. 重複訂房：她不小心重複訂了兩間房間，後來取消了其中一間。
7. 延長住宿：住宿期間，她想延長一天，但飯店房間已滿。
8. 房間損壞：她不小心損壞了房間的設施，系統需要處理賠償問題。
9. 結束住宿：最終，系統應該能正確計算所有費用，包括取消、重新訂房及損壞賠償的部分，並生成最終帳單。

測試範圍

針對 Emily 的故事，我們需要驗證以下幾個重要的功能點：

1. 預訂流程是否順利完成，並寄出確認郵件和付款記錄。
2. 修改預訂日期，系統是否正確更新房間價格與確認信息。
3. 系統能否處理部分日期取消，並進行部分退款。
4. 處理重新訂房，並生成新的訂房確認。
5. 系統是否能正確計算所有費用，並發送最終帳單。

測試案例

測試案例分析

• 功能覆蓋：測試案例基本涵蓋了預訂系統中的所有主要功能，從訂房到取消、付款失敗和損壞賠償等情境。
• 邊界情況處理：案例中處理了付款失敗重試、重複訂房和延長住宿這些邊界情況，檢查系統能否正確應對各種突發狀況。
• 異常處理：設計了如損壞設施和部分退款等異常情況的處理，這些案例能幫助確保系統面對複雜情境時的穩健性。

結論

透過 Soap Opera Testing 的測試方法，我們可以從使用者的角度，快速發現系統在複雜情境下的潛在問題。這種方法非常適合針對具有多樣化使用者行為和複雜流程的系統進行測試。

所以，如果你的系統經常會遇到各種不同的使用情境，不妨試試用這種「肥皂劇」式的測試法，不僅有趣，也能有效覆蓋大部分邊界和異常情況！